ALB（Application Load Balancer）がボトルネックになっていたか確認する方法を教えてください

ALB への急激なアクセス増加時にボトルネックになったかを確認する方法、および対処法をまとめました。

AWSテクニカルサポートノート

#Amazon EC2

#Application Load Balancer（ALB）

#Elastic Load Balancing (ELB)

#AWS

M.Shimizu

2023.08.15

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

※2024年11月25日更新

困っていた内容

ALB（Application Load Balancer）への急激なアクセス増加により処理が遅延し、一時的にサーバーエラーとなる事象が発生しました。ボトルネックが ALB 側か、もしくはバックエンドサーバー側かを切り分けたいのですが、ALB の性能限界に達していたか確認する方法を教えてください。

どう対応すればいいの？

ALB は負荷状況に応じて内部的にスケーリングが行われるため、最大接続数などの情報は非公開となっています。
そのため ALB の性能限界を明確に確認することはできませんが、以下 (1) ～ (3) の指標を確認することで、ALB もしくはバックエンドのどちらがボトルネックになっていたかを推測できます。

(1) 当該時刻に ALB のスケーリングが行われていたかを確認する

ALB への接続数が物理ノードの限界に達すると自動的にスケーリングが行われ、その際には必ず ENI（ネットワークインターフェース）も作成されます。

従ってアクセスが急増した時刻に ENI が作成されていたか確認することで、スケーリングが行われたか（つまり物理ノードの限界に達したか）を判断できます。以下に、CloudTrail で確認する手順を示します。

CloudTrail のイベント履歴でアクセスが急増した日時に絞り込み、CreateNetworkInterface イベントを検索します。

イベントの詳細内容を確認し、description の項目に該当する ALB 名が記載されていれば、当該 ALB でスケーリングが行われたと判断できます。

(2) ALB 側の限界により拒否された接続があるかを確認する

対象 ALB を CloudWatch で確認し、アクセスが急増した時刻に RejectedConnectionCount のメトリクスが記録されていれば、ALB 側の接続数限界によって処理できなかった接続があったと判断できます。

参考資料[1]より抜粋

RejectedConnectionCount
ロードバランサーが接続の最大数に達したため、拒否された接続の数。

※ ただし RejectedConnectionCount が記録されていなくても、ALB のスケーリングが行われている場合もあります。そのため ALB の性能限界に達したか否かはこのメトリクスの有無のみで判断せず、前述の (1) と併せて判断しましょう。

(3) サーバーエラーの原因がバックエンド側に起因していないかを確認する

上記 (1) (2) が確認できない場合は、バックエンドサーバー（EC2 や ECS）側の性能ひっ迫によりボトルネックになっていた可能性が考えられます。以下のような指標が記録されていないか確認してみましょう。

・ ALB 側で HTTPCode_Target_5XX_Count メトリクスが記録されていれば、バックエンドサーバー内部から 500 系のサーバーエラーが返されていたことを示します。また TargetResponseTime が上昇していれば、ALB 側ではなくバックエンド側で処理遅延が発生していたと判断できます。

参考資料[1]より抜粋

HTTPCode_Target_5XX_Count
ターゲットによって生成された HTTP 応答コードの数。これには、ロードバランサーによって生成される応答コードは含まれません。

TargetResponseTime
リクエストがロードバランサーから送信され、ターゲットからの応答を受信するまでの経過時間 (秒)。

・バックエンドサーバー（EC2）側のメトリクスや内部ログを確認し、当該時刻にCPU使用率やメモリ使用率の高騰が見られる場合は、バックエンドサーバー内部の処理がボトルネックになっていた可能性が考えられます。

もし ALB がボトルネックになっていた場合はどう対処すればよいですか？

AWS サポートを利用できるプランに加入されており、かつ ALB へのアクセスが急増する日時をあらかじめ予測可能な場合は、AWS サポートへ ELB の暖機申請を行うことを検討しましょう。

※2024年11月25日追記
Service Quotas を利用してユーザー側で暖機をすることが可能になりました。
詳細は下記の記事を参考にしてください。

新機能のロードバランサーキャパシティユニット (LCU) 予約で、ALBの暖機を試みてみた | DevelopersIO
https://dev.classmethod.jp/articles/lcu-reservation-alb/

もし予測できないアクセスの急増にも対応したい場合は、暖機申請が不要で ALB より多くのリクエストを処理できる NLB（Network Load Balancer）への置き換えも検討しましょう。
※ ただし ALB にしかない機能（AWS WAF との統合やリスナールール等）を使用している場合は、NLB への置き換えができない場合もあります。

以上、ALB がボトルネックになっているかの確認方法と、その対処法についてまとめてみました。この情報がどなたかのお役に立てば幸いです！